The use case is beyond web components. For example, 3rd party widgets or SDKs who do not want their styles to be affected by user's website code may want to use shadow DOM without web components. This is what we do. The other option for such apps is dynamic iframes. The good thing is that with the changes we make for shadow DOM, we automatically take care of dynamic iframes too by using the correct document.

yes, I'll reframe a bit, I was using Web Components as a bit of a stand-in term for shadow dom, but this is more accurate

I think we are potentially over simplifying by stating that solving shadow dom will solve iframes. They are two fundamentally different technologies even if they have overlap in terms of problems they solve.

See for example the need for

This is not needed for Shadow DOM. If we only worked on supporting Shadow DOM, this would be missed. That is because events inside an iframe will not appear outside the frame. While for Shadow DOM, events still have a capture phase and bubble phase outside of the Shadow root.

There will be other cases where behaviour differs between the two technologies.

We do not write special tests for shadow DOM. All our component testing is done using playwright's component testing. We run the same tests both with and without shadow DOM.

I'm not sure what this comment has to do with us? The RFC is for what we need to do to support shadow dom in our library.

I'm also suggesting that we run the same tests both with and without shadow DOM

we should create a custom React Testing Library renderer for our unit tests which can wrap each test's rendered dom in a shadow root.
... without needing to write many specific tests.

There will need to be specific tests as well, but they can be added as edge cases are discovered. For now I'd like to get all of our current tests running both ways.

I'm not sure what this comment has to do with us?

Not much. This was just me sharing how we handle this situation.

I think one way to think about this is supporting different root elements instead of just think about it as shadow DOM support. See #7743 for example. Components like modal and popover always treat document.body as their root element. Instead react-aria should provide options to treat any other element as a container element.

Possibly, what happens in the case of nested shadow doms though? Would we expect people to addWindowFocusTracking equivalent for each root and each hook/function that needs it? Would components need to accept a root element to pass down to hooks? context?

This wouldn't work for closed roots. This is why we want to re-think some of the ways parts of our library work. For example, FocusScope moves focus around for you when it's contain=true. This can't move into closed shadow roots, which is why the video tag breaks our FocusScope at the moment in certain cases. Instead, if we moved to a sentinel-based approach, we could let the browser handle the tab movement.

Initially I thought that supporting closed shadow root might not be a high priority at the beginning but you raised a good point about the video element. In that case, we do need to support both modes of shadow root.

Would we expect people to addWindowFocusTracking equivalent for each root and each hook/function that needs it? Would components need to accept a root element to pass down to hooks? context?

This might not be a good solution in the long run. But I can't answer much right now before going into the details of closed shadow root.

I think the best way to approach it is to come up with a setup where all new code is compatible and the existing code can be changed when someone needs it. I think in a while, it will be just about using a set of utilities.

We can start with the getOwnerWindow and getOwnerDocument eslint rule in more packages.

I think this is ambiguous

all new code is compatible

Does that mean it works in an application that has a single shadow dom at the root? that it can use video anywhere? that it can have 3rd party web components anywhere? that it can have shadow roots anywhere?

What if the new code is a new feature in an existing component or hook that has no support? what if that hook depends on lower hooks that don't have support and changing those hooks would also change how other components work.

It's a lofty goal and I think we should aim for support of everything. But it has to be moderated with the cost of implementation and ongoing support.

---

I don't believe this is true

it will be just about using a set of utilities

as I mentioned earlier, in order to support closed root (as an example), we have to rethink how many components and hooks are implemented.

---

I agree with this

We can start with the getOwnerWindow and getOwnerDocument eslint rule in more packages.

I agree. If the aim here is to add full support for shadow DOM (which will be great), this isn't as simple as adding utilities. When I say full support, I mean everything just works out of the box irrespective of the where a shadow DOM is located. And that will include much more than some utilities and will involve refactoring of certain sections.

We want to avoid maintaining a fork so we will try to do our best here. Right now we use patches which are a nightmare during upgrades.

I'm not sure what this has to do with the "help needed" section? Are you just saying it will be hard to create tests and examples?

Sorry for not being clear. I meant we will like to help here as much as possible so that we do not have to maintain a fork. At the end of the day, we want shadow DOM support to land up here.

A possible classification:
Container components that can have anything vs create name components such as RadioGroup that don't allow shadowdom's inside them

yes, I'll reframe a bit, I was using Web Components as a bit of a stand-in term for shadow dom, but this is more accurate

I think we are potentially over simplifying by stating that solving shadow dom will solve iframes. They are two fundamentally different technologies even if they have overlap in terms of problems they solve.

See for example the need for

This is not needed for Shadow DOM. If we only worked on supporting Shadow DOM, this would be missed. That is because events inside an iframe will not appear outside the frame. While for Shadow DOM, events still have a capture phase and bubble phase outside of the Shadow root.

There will be other cases where behaviour differs between the two technologies.

I'm not sure what this comment has to do with us? The RFC is for what we need to do to support shadow dom in our library.

I'm also suggesting that we run the same tests both with and without shadow DOM

we should create a custom React Testing Library renderer for our unit tests which can wrap each test's rendered dom in a shadow root.
... without needing to write many specific tests.

There will need to be specific tests as well, but they can be added as edge cases are discovered. For now I'd like to get all of our current tests running both ways.

Possibly, what happens in the case of nested shadow doms though? Would we expect people to addWindowFocusTracking equivalent for each root and each hook/function that needs it? Would components need to accept a root element to pass down to hooks? context?

This wouldn't work for closed roots. This is why we want to re-think some of the ways parts of our library work. For example, FocusScope moves focus around for you when it's contain=true. This can't move into closed shadow roots, which is why the video tag breaks our FocusScope at the moment in certain cases. Instead, if we moved to a sentinel-based approach, we could let the browser handle the tab movement.

I think this is ambiguous

all new code is compatible

Does that mean it works in an application that has a single shadow dom at the root? that it can use video anywhere? that it can have 3rd party web components anywhere? that it can have shadow roots anywhere?

What if the new code is a new feature in an existing component or hook that has no support? what if that hook depends on lower hooks that don't have support and changing those hooks would also change how other components work.

It's a lofty goal and I think we should aim for support of everything. But it has to be moderated with the cost of implementation and ongoing support.

---

I don't believe this is true

it will be just about using a set of utilities

as I mentioned earlier, in order to support closed root (as an example), we have to rethink how many components and hooks are implemented.

---

I agree with this

We can start with the getOwnerWindow and getOwnerDocument eslint rule in more packages.